I'm afraid the tag of a From header must be randomly chosen by the UA and cannot be the same all the time. The tag should never be used as a "password" or something like that.

nice to hear of you @ibc -- you are certainly right that the From-tag must be random (RFc3261 19.3 it MUST be globally unique and cryptographically random with at least 32 bits of randomness). The same section suggests Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. It is in fact a well-established implication of the end-2-end principle adopted largely in the IETF architecture, that as long as the explicit protocol spec is respected for interoperability reasons, implementors are encouraged to use the protocols for uses and use variations not contemplated before. Alone the number of TCP versions is rather confirming.

The bottom line is we are interested in this because it helps SIp troubleshooting, which is inherently a different enterprise, by linking a piece of information in SIP message to information found in analytics. For empirical reasons, from-tag is actually a practical place to do this -- while not guaranteed to survive, it occurs to traverse SBCs unchanged more often than proprietary header-fields or CAll-id.

anyhow don't feel compelled to adopt the patch, it is a very specific use-case, I just wanted to make the point that of course the tag will be generated randomly and neither is it a password -- it is to be used as a random, unique often-surviving reference number.

actually here another text making the point, section 19.3, which specifically encourages implementations to relate context to the otherwise opaque tag: A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it.

the principle is the same -- use additional properties of the tag for relate additional context to it

Thanks. I'll reopen the PR but AFAIU the new setting should be named register_from_tag_trail or similar, and it should be a string that will be appended to a randomly generated tag. Example:

• register_from_tag_trail: "foo-bar"

Each REGISTER will have a From tag as follows:

• tag=1234-1235-23434-3234-foo-bar
• tag=98798-456345-6757-45-foo-bar

Does it make sense?

thank you @ibc , almost there -- i think it makes sense to guarantee random properties by the mandatory part and permit some additional uses by an optional prefix. what would really help us is a capability to introduce a suffix that is variable -- it could specifically depend on source-ip, timestamp, config parameter, so that's easy to relate to any of these elements.

how would you feel about using a function ?: register_from_tag_trail: (config) => md5(config.foo, DAte.now/1000, source.ip) ? (very vague admittedly i haven't looked at the actual code)

AFAIU the new setting should be named register_from_tag_trail or similar, and it should be a string that will be appended to a randomly generated tag

OK done. @ibc please review

The register_from_tag_trail could be either a static string or a function that is evaluated before each REGISTER is sent

Hi guys, busy these days, will take a look to this soon.

Thanks @kkozlik, merged. It'll be available in the next release.